From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi@qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi@qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi@qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi@qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi@qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi@qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi@qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Tue Mar 14 23:22:05 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon@docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi@qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:05 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon@docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Tue Mar 14 23:22:05 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon@docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:05 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi@qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 14 23:22:05 2006 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 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: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 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: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon@docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 14 23:22:06 2006 Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) 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> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi@qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi@qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi@qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi@qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0001.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi@qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi@qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi@qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0001.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 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 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 -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0001.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0001.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi@qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon@docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi@qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon@docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0001.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon@docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi@qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0001.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0001.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon@docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Tue Mar 28 18:25:30 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi@qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi@qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi@qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi@qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi@qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0002.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi@qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi@qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:24 2006 Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi@qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 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: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0002.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 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: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi@qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 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 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 -----Original Message----- From: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0002.html From jsmsengine at gmail.com Fri Jan 13 02:17: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: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0002.html From tjarvi at qbang.org Fri Jan 13 04:25:31 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: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi@qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi@qbang.org _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 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: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi@qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon@docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 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: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi@qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon@docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >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 jsmsengine at gmail.com Sat Jan 14 06:19:46 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: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0002.html From tjarvi at qbang.org Sat Jan 14 06:27:33 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: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon@docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx@qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 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: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi@qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0002.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0002.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 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: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi@qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi@qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 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: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces@qbang.org [mailto:rxtx-bounces@qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon@docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx@qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue Mar 28 20:17:25 2006 Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) 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> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi@qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0003.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0003.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0003.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0003.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0003.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0003.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0003.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0004.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0004.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0004.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0004.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0004.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0004.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0004.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0005.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0005.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0005.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0005.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0005.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0005.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0005.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0006.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0006.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0006.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0006.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0006.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0006.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0006.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0007.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0007.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0007.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0007.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0007.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0007.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0007.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0008.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0008.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0008.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0008.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0008.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0008.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0008.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0009.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0009.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0009.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0009.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0009.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0009.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0009.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0010.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0010.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0010.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0010.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0010.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0010.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0010.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0011.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0011.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0011.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0011.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0011.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0011.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0011.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0012.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0012.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0012.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0012.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0012.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0012.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0012.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0013.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0013.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0013.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0013.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0013.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0013.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0013.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0014.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0014.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0014.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0014.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0014.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0014.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0014.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0015.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0015.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0015.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0015.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0015.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0015.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0015.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0016.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0016.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0016.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0016.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0016.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0016.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0016.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0017.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0017.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0017.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0017.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0017.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0017.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0017.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0018.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0018.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0018.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0018.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0018.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0018.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0018.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0019.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0019.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0019.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0019.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0019.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0019.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0019.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0020.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0020.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0020.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0020.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0020.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0020.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0020.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0021.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0021.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0021.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0021.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0021.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0021.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0021.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0022.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0022.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0022.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0022.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0022.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0022.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0022.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0023.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0023.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0023.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0023.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0023.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0023.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0023.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0024.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0024.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0024.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0024.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0024.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0024.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0024.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0025.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0025.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0025.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0025.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0025.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0025.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0025.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0026.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0026.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0026.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0026.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0026.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0026.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0026.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0027.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0027.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0027.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0027.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0027.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0027.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0027.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0028.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0028.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0028.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0028.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0028.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0028.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0028.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0029.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0029.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0029.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0029.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0029.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0029.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0029.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0030.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0030.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0030.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0030.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0030.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0030.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0030.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0031.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0031.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0031.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0031.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0031.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0031.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0031.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0032.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0032.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0032.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0032.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0032.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0032.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0032.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0033.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0033.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0033.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0033.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0033.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0033.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0033.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0034.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0034.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0034.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0034.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0034.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0034.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0034.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0035.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0035.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0035.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0035.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0035.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0035.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0035.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0036.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0036.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0036.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0036.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0036.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0036.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0036.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0037.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0037.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0037.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0037.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0037.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0037.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0037.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0038.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0038.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0038.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0038.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0038.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0038.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0038.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0039.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0039.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0039.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0039.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0039.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0039.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0039.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0040.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0040.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0040.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0040.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0040.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0040.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0040.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0041.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0041.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0041.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0041.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0041.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0041.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0041.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0042.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0042.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0042.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0042.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0042.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0042.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0042.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0043.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0043.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0043.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0043.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0043.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0043.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0043.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0044.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0044.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0044.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0044.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0044.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0044.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0044.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0045.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0045.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0045.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0045.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0045.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0045.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0045.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0046.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0046.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0046.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0046.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0046.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0046.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0046.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0047.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0047.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0047.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0047.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0047.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0047.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0047.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0048.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0048.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0048.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0048.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0048.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0048.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0048.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0049.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0049.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0049.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0049.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0049.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0049.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0049.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0050.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0050.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0050.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0050.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0050.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0050.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0050.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0051.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0051.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0051.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0051.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0051.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0051.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0051.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0052.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0052.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0052.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0052.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0052.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0052.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0052.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0053.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0053.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0053.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0053.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0053.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0053.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0053.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0054.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0054.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0054.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0054.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0054.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0054.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0054.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0055.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0055.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0055.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0055.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0055.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0055.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0055.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0056.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0056.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0056.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0056.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0056.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0056.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0056.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0057.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0057.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0057.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0057.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0057.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0057.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0057.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0058.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0058.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0058.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0058.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0058.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0058.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0058.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0059.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0059.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0059.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0059.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0059.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0059.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0059.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0060.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0060.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0060.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0060.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0060.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0060.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0060.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> 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. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0061.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0061.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: 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 -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0061.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0061.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> 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. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, 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?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > 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. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >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?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >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? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >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. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0061.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 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 From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I 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 a object of 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 initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern 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? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } 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. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0061.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0061.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -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 Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 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 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> 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?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> 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? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> 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. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: 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 From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wro